Typically, process plants (such as chemical refinery plants and drug manufacturing plants, for example) include many field devices which control and measure parameters within the process. Each field device may be a control device (such as a flow valve controller), a measurement device (such as a temperature gauge, pressure gauge, flow meter, etc.) and/or any other device that affects or determines a value associated with a process. Until the past decade or so, field devices have typically been rather simple devices which were controlled either manually or electronically and which produce output readings either electronically or on a gauge connected to the device. However, these devices typically only provide limited information to a controller such as analog signals pertaining to the readings or measurements made by these devices.
More recently, so called "smart" field devices have been developed. Smart field devices are capable of communicating with a process controller and/or a management system associated with the device. Typical smart field devices are capable of transmitting an analog signal indicative of the value associated with the device, for example, a measurement value, and of storing and also digitally transmitting detailed device--specific information, including calibration, configuration, diagnostic, maintenance and/or process information. Some smart devices may, for example, store and transmit the units in which the device is measuring, the maximum ranges of the device, whether the device is operating correctly, troubleshooting information about the device, how and when to calibrate the device, etc. Furthermore, a smart field device may be able to perform operations on itself, such as self-tests and self-calibration routines. Exemplary smart devices include devices which follow the HART (Highway Addressable Remote Transducer) protocol (HART devices), the Fieldbus protocol (Fieldbus devices), the Modbus protocol, and the DE protocol. However, other smart device protocols may exist or be developed in the future to support different types of smart devices.
Currently, every conventional and smart device is capable of performing one or more specific input and/or output functions with respect to a process. An input function is any function which measures or reads a value associated with a process, such as the function performed by a temperature or pressure measurement device. An output function is any function that changes something within a process, such as the functions performed by a valve or flow controller. Furthermore, some smart devices, such as Fieldbus devices, can perform control functions which are functions associated with the control of a process. Each input, output and control sub-function performed by a device is referred to as a "block." By definition, therefore, each device includes at least one and maybe more blocks. Fieldbus devices usually include multiple blocks (e.g., one or more input, output, and control blocks), and, while HART devices do not include blocks per se, the contents of a HART device may be conceptualized as constituting one and only one block.
Each block and, therefore, each device includes one or more "parameters." A parameter is an attribute of a block which characterizes, affects or is somehow otherwise related to the block. Parameters may include, for example, the type of the block, the maximum operating or measurement range of a block, the mode of a block, the value of a block measurement, etc.
Likewise, each parameter has one or more properties associated therewith, and each of those properties defines or describes the information within the parameter. For example, the temperature parameter of a temperature measuring device has a label property which stores the name of the parameter (e.g., "temperature"), a value property which stores the value of the parameter (e.g., the actual measured temperature), and a units property which stores the units in which the temperature PATENT 06005/33102 value is expressed (e.g., degrees centigrade or degrees fahrenheit). A device or a block configuration comprises a set of values for each of the properties of each of the parameters associated with a device or a block.
As noted above, smart field devices are developed so that communication therewith must be performed in one of several available protocols (the HART and Fieldbus protocols, for example). These protocols allow device manufacturers to provide device-specific types of information for a device and, of course, the particular types of information are different for each type of smart field device. Consequently, these protocols are complex and difficult to use in device programming. More particularly, some of these protocols do not provide a completely consistent method for communicating with every smart device conforming thereto. Instead, these protocols, such as the HART protocol, merely provide a way for device manufactures to specify what information is available from each smart field device and how to retrieve that information.
Communication with smart devices has been simplified to some extent with the advent of device description languages (DDL) and device descriptions which are provided by the manufacturers of smart field devices. A DDL is a human-readable language that provides a protocol for describing the data available from a smart device, the meaning of the data associated with the smart device and retrieved therefrom, the methods available for implementation of the smart device, the format for communicating with the smart device to obtain data, user interface information about the device such as edit displays and menus, and information for handling or interpreting other information pertaining to a smart device.
DDL source files comprise human-readable text written by device developers. These files specify all the information available about a device between the device arid a bus or a host to which the device is connected. Basically, in developing a DDL source file for a device, a developer uses the DDL language to describe core or essential parameter characteristics of the device as well as to provide group-specific, and vendor-specific definitions relating to each block, parameter, and special feature of a smart device.
A DDL source file is compiled into a binary format to produce a machine-readable file known as a device description (DD) which can be provided to a user by the device manufacturer or a third-party developer to be stored in a host system, such as a management system. In some cases, for example in Fieldbus devices, DDL source files may be stored in a smart device and transferred from the smart device to a host system. When the host system receives a DD object file for a smart device, it can decode and interpret the DD to derive a complete description of the interface with the device.
DDS is a general software system developed and provided by Fisher-Rosemount Systems, Inc. and/or Rosemount, Inc. for automatically decoding and interpreting the DD's of smart devices. More particularly, DDS is a library of routines which, when called by a host, interprets the DD of a smart device to provide the host with information pertaining to the smart device, including information pertaining to: (1) the setup and configuration of the smart device; (2) communication with the smart device; (3) user interfaces; and (4) methods available for use in conjunction with the smart device. One extremely useful application of DDS is in providing a consistent interface between a host system and one or more smart devices having associated DDL source files (and corresponding DD object files).
Although DDS, DDL and DD's are generally known in the art, more information pertaining to the specific function and format of DDL's, and of Fieldbus DDL in particular, can be found in the InterOperable Systems Project Foundation's manual entitled "InterOperable Systems Project Fieldbus Specification Device Description Language" (1993). A similar document pertaining to the HART DDL is provided by the HART foundation.
A management system is a system which interacts with one or more smart field devices to read any of the device, block, parameter, variable, or configuration information associated with those devices. Typically, a management system comprises a personal computer having appropriate communication ports which allow it to interconnect to, communicate with, and reconfigure a smart device. Management systems may be on-line, that is, have a hard-wired or other permanent connection with a smart device, or may be portable and capable of being periodically connected to a smart device to reconfigure that smart device.
Management systems typically perform a wide variety of functions with respect to smart devices within a system. For example, management systems may be used to provide users with information (e.g., values of variables or parameters) pertaining to the state of a process and to each of the smart field devices associated with or connected to the process. Management systems may also be used to enable a user to monitor a process and control the process by reconfiguring smart devices within the process as necessary.
The software routines which are used to perform functions within a management system using features provided by the system are typically referred to as applications. Typically, management systems implement applications provided by individual smart device manufacturers to implement changes on, and read data from, a particular smart device. As a result, various applications within a management system often do not share a common or consistent interface, and the transition from one application to another is therefore cumbersome and time-consuming. Further, smart device configuration data, configuration logs, and smart device diagnostic data created and stored by different applications are decentralized and cannot be cross-referenced because this data may be stored in diverse formats, in different databases and, in some cases, in proprietary formats. Consequently, tasks that could be common to each device within a system must be duplicated in separate applications.
A management system which implements such separately developed applications typically has no way to view information pertaining to all the smart devices in a plant or a process simultaneously because the applications for each device must be run separately. Furthermore, it is difficult for users to write applications that provide a comprehensive view of data pertaining to multiple, different devices in a process because users typically do not have a great familiarity with DDS or with the DDL and DD's associated with each of the devices within a process. Even if a user does have such familiarity, such applications are time-consuming and expensive to develop and must be updated each time a new smart device is added to the system.
Another cumbersome aspect of developing applications for management systems is programming the application to perform the numerous tasks relating to and necessary for communication between a user and each smart device within a system. A developer not only must be attentive to details involving how to communicate with each separate device, but that developer must also pay particular attention to how information is presented to a user via, for example, a display. This task is made more difficult because typical applications do not use consistent user interface protocols. Instead each of the interface functions requires much programming time and effort, which must be repeated each time a new smart device is added to the system.
Still further, applications typically allow a user to view a current configuration of a device, block, or parameter within a process, but those applications do not allow the user to view past configurations or to display multiple configurations simultaneously to compare such configurations.